1. Field of the Invention
The present specification relates generally to communication of data. This specification also relates generally to communication of packet data on a wireless interface between a mobile device and an access network in a communication system.
2. Description of the Related Art
A communication system is typically a facility that enables communication between two or more entities such as, but not limited to, user equipment and/or networks entities and/or other nodes associated with the communication system. The communication may include, for example, communication of various kinds of data such as voice data, electronic mail (email), text messages, content data, multimedia and so on. The communication system may be used for provisioning the users thereof with various types of services.
A communication system typically operates in accordance with a given standard or specification which commonly sets out what the various elements of the system are permitted to do and how that should be achieved. For example, the standard or specification may define if the user, or more precisely, user equipment is provided with a circuit switched service or a packet switched service or both. Communication protocols and/or parameters which may be used for the connection are also typically defined. For example, the manner of how communication may be implemented between the user equipment and the elements of the communication network is typically based on a predefined communication protocol. In other words, a specific set of “rules” on which the communication may be based on is preferably defined to enable the user equipment to communicate via the communication system.
The communication may be provided, for example, via fixed line and/or wireless communication interfaces. A common feature of data communication systems wherein data is transported on wireless interfaces to the user equipment is their ability to provide mobility for the users thereof. Thus these wireless systems may also be referred to as mobile communication systems. Representative, non-limiting examples of communication systems providing wireless communication include the public land mobile network (PLMN), satellite based communication systems and wireless data networks such as the Wireless Local Area Network (WLAN).
The wireless communication systems may be provided based on radio access entities known as cells. Hence such systems are often referred to as cellular communication systems. In a cellular system, a base transceiver station (BTS) of the radio access network (RAN) typically provides a wireless communication facility that serves mobile devices such as, but not limited to, mobile stations (MS) and/or similar mobile user equipment (UE) via an air and/or radio interface within the coverage area of the cell. It shall be appreciated that the name of the station may vary between the different communication systems. For example, names such as base station and Node B may be used for the stations of the communication system. In the context of Wireless Local Area Networks the stations may be called Access Points. The size and shape of the cells may vary from cell to cell. Several cells may also be grouped together to form a larger service area. A base station may provide more than one cell.
Examples of the cellular communications systems include standards such as, but not limited to, the GSM (Global System for Mobile communications) or various GSM based systems such as GPRS (General Packet Radio Service), AMPS (American Mobile Phone System), DAMPS (Digital AMPS), WCDMA (Wideband Code Division Multiple Access), TDMA/CDMA (Time Division Multiple Access/Code Division Multiple Access) in UMTS (Universal Mobile Telecommunications System), CDMA2000, i-Phone and so on.
In representative third generation systems such as the CDMA 2000, the UMTS, etc., the mobile devices may establish a continuous connection through the radio access network (RAN) and the core network (CN) of the cellular system. For example, the continuous connection may be established through an access network controller such as a base station controller (BSC) and/or packet control function (PCF) of the radio access network (RAN) and/or an access gateway of the core network. The access gateway and the access network controller may then maintain context files of the mobile devices and retain these context files for continuous connectivity.
If the mobile device is switched off or is otherwise prevented from communication with the access network, then the connection is typically lost and will generally have to be rebuilt when the mobile device is switched back on or when the reason blocking the communication is removed. Once the access gateway and access network controller determine that the mobile device has been switched off, or is otherwise out of reach, the context files for the mobile device are usually torn down.
It may happen that a mobile device is not deliberately deactivated but rather falls out of a coverage area, or enters within a blind spot in the coverage area. This may result, for example, when the user moves behind a tall building, into a tunnel, out of a cell and so on. Should this happen, then the mobile device may be temporarily unable to respond to requests or other messages from an access gateway or an access network controller. Once the mobile device comes back into the radio coverage, it then preferably rebuilds the context file with the access network controller and the access gateway. This may, in many cases, cause additional and unwanted signaling over the radio link. In addition to causing load on the radio link, this additional signaling may also reduce battery life of the mobile device.
For example, it has been proposed that in the CDMA2000 the support for always-on mobile devices must be a mandatory feature of the access gateway. The access gateway may be provided by means of a packet data support node (PDSN). In the proposal, the ‘Always On’ service typically maintains the subscriber's packet data session in the local network. In brief, in the Always On service the access gateway is generally arranged such that it does not initiate release of a packet data session unless it is certain that the mobile device is no longer reachable.
Two types of services are often currently proposed, the Mobile IP service and Simple IP service. One of the major differences between the Mobile IP service and Simple IP services has to do with the way that the mobility detection management is handled. With the Simple IP service, the packet data service is typically disrupted when the mobile device moves to another access gateway or point of attachment. The Mobile IP service generally aims to try to avoid any disruptions in the service is such occasions.
Proposal No. TR45.6/2002.08.05.10r1, dated August 2002, prepared for TIA (Telecommunications Industry Association) Subcommittee Adjunct Wireless Packet Data Standards and titled Proposed Resolution to Battery Life and Reachability issues in PN-3-4732-RV2-A (Research In Motion Ballot comment #1), by Dan Willey and Willy Verbestel, relates to these issues. The proposal describes how a packet data support node (PDSN) or access gateway may perform an operation known as the layer 2 Point-to-Point Protocol (PPP) link (LCP) Link Layer Protocol Echo-Request message. Those interested can find a more detailed description of the Echo-Request message from the Internet Engineering Task Force (IETF) document RFC 1661.
In a communication system operated in accordance with the protocol, a mobile device typically responds to a LCP Echo-Request message with a LCP Echo-Reply message within a specified time. The PDSN may maintain a configurable Echo-Reply-Timeout timer and an Echo-Request-Retries counter. Upon entering the Internet Protocol Control Protocol (IPCP) Opened state on a Point-to-Point Protocol (PPP) session configured for the Always On Service, the PDSN may also start a PPP inactivity timer for the PPP session in question. Upon expiration of the PPP inactivity timer, the PDSN commonly sends an LCP Echo-Request message over the main service instance, and generally starts the Echo-Reply-Timeout timer for the PPP session in question. The PDSN may also initialize the Echo-Request-Retries counter to a configurable integer value. The arrangement is often such that if the Echo-Request-Retries counter value is greater than zero upon expiration of the Echo-Reply-Timeout timer, the PDSN sends an LCP Echo-Request message, decrements the Echo-Request-Retries counter by one, and/or starts the Echo-Reply-Time out timer. For the Simple IP service, the proposal is typically that the mobile station is preferably to be informed of the value of the PPP inactivity timer.
Upon receipt of an LCP Echo-Reply message for the PPP session in question, the PDSN generally stops the Echo-Reply-Timeout timer, normally resets the Echo-Request-Retries counter, and typically restarts the PPP inactivity timer. Upon expiration of the Echo-Reply-Timeout timer when the Echo-Request-Retries counter value is equal to zero, the PDSN usually releases the PPP session. In most cases, the PDSN can only tear down the PPP after the expiration of the PPP inactivity timer. However, if the mobile device is out of the radio coverage long enough, then the network may release the packet data session. Thus, the mobile device may still need to restart the packet data session.
Furthermore, in order to preserve battery life for the always-on mobile device and to avoid wasting air interface capacity, the proposal suggests that a two hour PPP inactivity timer value be used for the always-on mobile device.
The above described operation may result in a substantive amount of signaling and waste of resources. Further, the current CDMA2000 Wireless IP network and radio access network still do not generally satisfactorily support the ‘Always On’ service when the mobile station is temporarily out of coverage. The proposal typically offers only limited relief for the Simple IP services.
The requirement of never tearing down the PPP may also violate the approved CDMA2000 specifications. The PDSN generally must comply with any requests by the RAN to clear the resource via Clear Procedures. Furthermore, the current design commonly has the Echo-Request-Retries as a configurable value. This value may be set fairly high to ensure the session is preserved. A drawback of this is that the RAN and PDSN resources are often unnecessarily allocated. Furthermore, the proposal typically necessitates implementation of trigger and timer logics in the mobile station.